MEMORANDUM TO: Distribution 



Sept. 13, 1988 



SUBJECT: Compression of messages in TPF 

Increasingly, we find that traffic through the Prodigy network is 
related to transactional requests such as shopping, banking, travel, 
etc. In order to reduce the response times to subscribers using these 
services it appears desireable to compress transactional messages at TPF 
before they are sent to the subscriber. This memorandum provides 
specifications for such an implementation. As per discussions held 
9/13/88, Jim Beall would like to see this implemented in release 7.0 of 
the reception system. 



Currently Objects may be compressed by the Producer system and 
de-compressed on the reception system. We propose that transactional 
response messages can be compressed on TPF using the same algorithm as 
that for objects, and de-compressed on the reception system using the. 
same de-compression algorithm. Required is a means for recognizing when 
a message is compressed and a means for determining whether a reception 
system can support message compression. 



CONVENTIONS: 

The DIA FMO Compression/Compaction hit indicator is set to 1 when a 
reception system which supports message compression sends a Request 
message upstream. 

Before TPF returns n "Response" to n reception system it will examine 
the FMO compression bit (stored in ..he IPQF.) to determine whether it 
should invoke the compression routine. If the response is compressed TPF 
will leave, this bit on (1) when the message is sent to the requesting 
reception system. 

The use of the compression bit on the "Request" indicates that the 
reception system is capable of dealing with compression. This provides 
us with a migration path: an ability to support back-level reception 
systems . 

Objects are not to ho compressor* by TPF. 

The MA Compression Hinder (FM1271 is t ho Inst OTA header in a rrmssage. 

Compression is only to bo done n.pon tlm "data" portion of a message. No 
DIA headers are to bo compressed. FMfiA TEXT and FN 9 TEXT are not to be 
compressed . 

Only messages destined for the reception system are to be compressed 
and, again, only if they are responses to requests made with the FMO 
compression bit set to 1. 



In addition to the FMO compression hit setting, the DIA FM127 header is 
to be included when sending comprised messages from TPF to the 

reception system. 

The reception system interface to the de-compression routine should 
lonform to the current interface which exists for object de-compressio^ 
Upon encountering a "Response" with the FMO compression set to th. 
Receotion system should look for an FH127 header. This header contains 
^ fame "information as is contained in the existing OHJcc-t Compres, 
Segment It should be used In the same fashion when calling the 
decompression routine. Messages should be de-compressed before they are 
handed off to applications. 

DIA FM127 Header layout: 

n . . Header Length x'08* 0000 1000 

! '"';*;;;;; *. Header Typo x' 1 27 ' 0111 1111 

Note: Concatenation indicator is off. 

RvtPs 2-3 Length of compressed data 

y " Note: Intel format (low byte, high byte) 

n vt „ l . 5 Length of data bo fore compression 

tiyZ Note: Intel format (low byte, high byte) 

, .... Decompress ion Table Number 
Byte 7 Reserved x' 00* 0000 0000 

It is highly desireable to include this implantation in plans 
for the next release of the reception system. 
Thank you for your cooperation. 

Robert Filopp 



Byte 
Byte 



cc: Mr. C. Barlow 
Mr. L. Briney 
Mrs. J. Rothman 



